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ABSTRACT 

This  paper  presents  a  method  that  can  he  used  for  the  elicitation  and  specification  of 
requirements  and  high-level  design.  It  supports  stakeholder-based  modeling,  rapid  feasi¬ 
bility  feedback  to  marketing,  and  the  interpersonal  dynamics  that  are  necessary  to  de¬ 
velop  a  product.  The  method  centers  on  the  role  of  the  facilitator,  an  independent  agent 
whose  purpose  is  to  build  the  Integrated  System  Model  (ISM).  The  ISM  is  the  product 
of  merging  the  independent  system  views  from  all  stakeholders  at  any  given  abstraction 
level.  Formulation  of  this  method  was  based  on  the  real-world  experience  of  developing 
a  complex,  high-technology  medical  product  with  critical  time-to-market  pressures.  It 
has  proven  to  be  a  practical  approach  to  the  evolution  of  requirements  definition  and 
provides  a  necessary  link  to  the  marketing  aspect  of  a  product. 
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1  Introduction 


This  paper  presents  an  experience  in  which  requirements  engineering  is  done  in  a  very  adverse 
environment.  From  the  experience,  a  method  called  the  Facilitator  Method  is  derived.  The  term 
“facilitator”  is  used  because  the  analyst  acts  as  an  independent,  neutral  agent  that  facilitates 
diverse  stakeholders  actively  developing  the  system  model.  For  this  and  many  other  industrial 
projects,  requirements  definition,  requirements  specification,  and  design  activities  are  performed  in 
a  continuum  rather  than  as  clearly  demarcated  subprocesses.  The  full  definition  and  specification 
of  a  product  require  the  collaboration  and  contribution  of  many  people  and  is  done  based  on 
precedence.  The  history  of  the  technology  and  the  history  of  the  people  developing  the  product 
determine  what  the  product  looks  like.  A  product  is  designed  based  on  a  combination  of  prototypes, 
i.e. ,  an  existing  product  line  for  the  company,  what  exists  in  the  market,  and  what  is  in  the  heads 
of  the  development  staff  and  customers.  Using  these  people  to  the  fullest  extent  possible  during 
requirements  definition  is  one  goal  of  the  facilitator  method. 

The  facilitator  method  addresses  specifically  marketing  concerns  and  project  planning  needs. 
Information  that  helps  determine  market  feasibility  is  solicited  from  stakeholders  as  the  system 
definition  evolves.  The  model  maintains  focus  on  the  risk  of  not  meeting  the  market  requirements  for 
the  product,  including  features,  cost,  and  time-to-market.  The  method  allows  marketing  feedback 
and  decisions  to  be  made  at  each  abstraction  or  conceptual  level  of  the  requirements  and  design 
definition.  The  leveling  approach,  when  combined  with  market  feasibility  information  allows  losses 
to  be  minimized,  incremental  investment  decisions,  and  effective  concurrent  design  efforts.  This 
leveling  approach  is  common  to  most  analysis  methods. 

Another  aspect  of  the  facilitator  method  is  that  it  attempts  to  address  the  human  factors  element 
of  getting  project  requirements  and  a  design  definition  accomplished.  Diverse  stakeholders  present  a 
challenge  to  achieving  a  single  definition  that  is  comprehensive  and  understood  by  all  stakeholders. 
Each  stakeholder  embodies  a  tradition,  a  set  of  priorities  or  interests,  specific  training,  and  very 
often  a  language  different  from  that  of  the  others.  The  stakeholders  require  a  medium  of  exchange 
and  a  neutral  mechanism  for  achieving  a  common  understanding  [1],  Often  communicating  face-to- 
face  in  a  roundtable  fashion  hides  elements  of  the  diversity  that  exist.  Without  a  means  to  anchor 
the  discussions  that  type  of  communication  is  ineffective.  With  a  concrete,  neutral  mechanism  in 
which  the  stakeholders  are  invested,  the  communication  is  definitive  and  real  progress  can  be  made. 

Leite  and  Freeman  laid  the  foundations  for  using  viewpoint  resolution  as  a  means  to  validate 
and  formulate  a  more  complete  picture  of  requirements  during  the  elicitation  process  [2].  Viewpoint 
resolution  in  their  paper  was  a  process  of  soliciting  a  mental  position  or  viewpoint  from  significant 
actors  in  a  project.  The  discrepancies  between  viewpoints  were  evaluated  and  eventually  integrated 
into  a  single  solution  or  view.  They  did  preliminary  controlled  studies  that  demonstrated  that  using 
differing  viewpoints  enhanced  the  requirements  elicitation  process.  They  did  not  address  the  issue 
of  scaling  their  method  for  larger  projects,  in  particular  the  fact  that  it  would  take  significant 
resources  and  time  to  do  a  large  project  in  the  way  they  proposed. 

The  facilitator  method  presented  in  this  paper  uses  a  modified  form  of  viewpoint  resolution 
to  achieve  requirements  definition  quickly  for  large  projects.  Viewpoint  resolution  as  introduced 
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by  Leite  and  Freeman  is  different  from  the  method  described  here  in  a  number  of  ways.  For  one, 
the  facilitator  method  does  not  specifically  use  formal  rule-based  models  and  multiple  analysts. 
The  stakeholders,  rather  than  the  analyst,  become  responsible  for  representing  their  viewpoints 
by  graphical  means  and  supporting  it  with  annotated  data.  For  another,  the  generation  of  a 
model  happens  at  the  same  time  the  elicitation  process  is  occurring,  unlike  the  Leite  and  Freeman 
method.  This  speeds  up  the  development  process  when  the  scale  of  the  project  is  increased  and 
many  diverse  stakeholders  are  involved.  Finally,  the  facilitator  method  is  a  more  dynamic  process 
of  merging  viewpoints  and  defining  requirements  as  completely  as  practical  at  any  one  point  in 
time.  It  deals  with  the  fluidity  of  contingencies,  politics,  interpersonal  dynamics,  and  the  evolving 
nature  of  viewpoints. 

This  remainder  of  this  paper  describes  a  case  study  that  served  as  the  seed  for  the  facilitator 
method  and  then  describes  the  method  in  detail.  We  conclude  with  a  look  at  future  work. 

2  Case  Study 

The  experience  presented  in  this  paper  happened  over  a  period  of  fourteen  months.  The  product 
was  a  complex,  high-technology  medical  system.  The  overriding  requirement  was  meeting  the  time- 
to-market  deadline.  The  product  sold  for  over  one-million  dollars  each  and  the  investment  capital 
was  very  high.  The  company  had  bought  out  a  small  25-person  firm  that  made  chemical  research 
systems  using  the  application  technology  that  was  to  be  applied  to  the  medical  product.  The  new 
product  was  substantially  different  from  the  existing  one,  but  a  prototype  was  built  based  on  the 
chemical  research  system  that  existed  in  the  previous  company. 

The  company  grew  quickly  and  at  the  time  of  first  shipment  of  the  beta-test  product  there  were 
over  250  employees.  Many  people  were  brought  together  very  quickly  from  diverse  backgrounds. 
Those  who  were  experienced  in  the  application  area  had  worked  for  one  of  about  five  existing 
companies  in  the  market.  Many  of  those  people  were  scientist  in  physics  or  chemistry.  Most  of  the 
engineers  had  little  to  no  familiarity  with  the  application  area  and  were  also  brought  together  from 
a  diverse  set  of  training  and  experiences.  All  the  people  involved  were  highly  skilled,  including  the 
medical  technicians  (who  acted  as  surrogate  customers),  the  production  staff,  marketing  and  the 
service  technicians.  Since  the  company  was  being  formed  at  the  same  time  that  the  product  was 
being  defined,  many  of  the  required  processes  were  not  in  place  and  were  built  as  the  development 
went  along.  In  addition,  since  it  was  a  medical  product,  FDA  approval  was  critical. 

Once  the  proof-of-concept  prototype  had  been  built,  the  results  were  demonstrated  at  an  annual 
medical  trade  show.  The  company  then  launched  into  full-scale  engineering  of  the  product  that 
was  going  to  be  introduced  at  the  next  show.  At  the  time  work  on  the  actual  product  began,  the 
company  was  quite  fragmented  and  engineers  were  unproductive  because  they  did  not  have  any 
good  specification  from  which  to  work.  The  only  things  that  existed  were  preliminary  marketing 
documents  that  described  the  product  in  terms  that  would  sell  to  a  customer.  The  scientists  as 
a  collective  understood  the  very  complex  application,  but  did  not  know  how  to  specify  it  for  the 
engineers.  The  engineers  struggled  to  learn  the  application  area,  but  it  was  very  complex  and  they 
felt  pressured  by  the  time-to-market  requirement.  Most  of  the  managers  were  scientist  as  were  the 
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Figure  1:  Initial  Viewpoint  of  Surrogate  Customer. 


people  that  had  to  do  the  application  programming.  These  application  programmers  had  to  have 
a  system  upon  which  to  layer  their  software.  The  key  to  moving  forward  was  to  begin  to  get  the 
system  defined  in  a  way  that  the  engineers  could  build  from,  one  step  removed  from  the  application 
area. 

2.1  Product  Development  Process 

At  the  beginning  of  the  project,  many  ineffective  meetings  took  place  and  the  frustration  level 
was  very  high.  Eventually,  an  analyst  (one  of  the  authors,  R.  Gonzales)  met  with  the  stakeholders, 
the  unofficial  technical  leaders  from  each  group,  and  sketched  out  with  them  independent  models 
of  how  they  saw  the  system.  They  used  data-flow  diagrams  with  real-time  extensions.  Figures  1 
and  2  show  simplified  example  diagrams  given  by  two  representative  stakeholders.  In  the  figures, 
rectangles  represent  elements  outside  the  system,  circles  represent  transformation  of  data,  and 
arrows  are  the  data  flows  themselves.  As  the  modeling  proceeded,  the  data-flow  technique  was 
introduced  to  the  stakeholders,  but  they  often  strayed  away  from  the  notation. 

After  several  models  were  created  from  the  individual  stakeholders,  they  were  combined  and 
made  into  an  integrated  system  model.  This  merged  viewpoint  is  illustrated  in  Figure  3.  The 
merged  view  reflects  the  views  captured  in  figures  1  and  2  together  with  the  views  of  other  stake- 
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Figure  2:  Initial  Viewpoint  of  Application  Scientist. 


holders.  (Merging  is  discussed  in  more  detail  below.)  The  system  model  was  then  distributed 
and  communication  between  the  stakeholders  began  to  take  place.  As  the  model  was  iterated,  it 
became  clear  to  the  stakeholders  which  areas  needed  to  be  defined  first  and  which  areas  would 
become  critical  paths.  The  same  process  was  followed  for  each  of  the  critical  areas,  except  that  the 
stakeholders  changed.  The  areas  that  posed  greatest  risk  were  those  areas  where  the  most  diverse 
set  of  stakeholders  existed.  Once  the  modeling  had  been  done  for  these  critical  areas,  the  system 
model  changed  and  the  model  that  emerged  was  one  that  the  stakeholders  were  content  with  at 
the  system  level. 

While  the  edict  to  be  ready  with  a  product  in  a  year  remained  in  place,  there  was  still  some 
latitude  in  wliat  would  actually  be  delivered  in  the  product.  Moreover,  the  development  staff 
could  request  additional  resources.  Information  about  how  long  it  would  take  to  develop  each  of 
the  components  in  the  system  was  sought  in  the  same  manner  as  before,  namely  separately  from 
each  stakeholder.  By  asking  for  specifics  on  resources  and  time,  further  definition  was  required  by 
the  stakeholders.  Of  course,  this  had  an  effect  on  the  system  model.  The  results  of  this  process 
were  a  new  model  at  the  system  level,  a  model  for  three  of  the  most  critical  areas  of  the  system, 
and  a  time-line.  In  the  process,  the  marketing  staff  and  management  were  forced  to  make  some 
compromises  on  wliat  would  be  shipped  and  the  technical  staff  prioritized  the  various  parts  that 


4 


Figure  3:  Merged  Viewpoints  from  Multiple  Stakeholders. 

needed  to  be  built  so  that  the  minimum  system  could  be  delivered. 

Several  months  into  the  development  of  the  system  it  was  recognized  that  a  key  component 
was  not  going  to  be  available  in  time  for  the  application  scientists  to  perform  the  development 
needed  on  the  actual  system.  At  that  point  an  existing  component  used  in  the  prototype  was 
made  to  fit  into  the  new  system  and  development  continued.  This  was  the  only  significant  problem 
that  was  encountered.  The  data  necessary  for  FDA  approval  was  taken  before  the  product  was 
shipped.  The  beta-test  system  was  shipped  just  before  the  show  and  results  from  the  new  system 
were  demonstrated  at  the  show.  Some  of  features  of  the  product  were  not  quite  competitive,  but 
it  had  other  distinctive  features  that  set  it  apart.  The  fact  that  the  company  was  at  the  show  with 
a  real  product  made  it  a  contender.  This  was  the  goal  of  the  company. 

2.2  Lessons  Learned 

This  was  a  high-pressure  experience  and  during  development  there  was  never  a  moment  that 
product  shipment  was  certain.  In  an  ideal  world,  one  might  observe  that  the  schedule  requirements 
were  not  reasonable.  It  was,  however,  realistic  in  that  highly  competitive  market,  and  similar 
market  pressures  do  exist  for  other  products.  While  the  analyst  in  this  case  study  was  rather 
experienced,  the  standard  methods  that  were  available  for  her  to  use  were  too  inefficient.  This  was 
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an  extreme  case,  but  generally  the  real-world  still  cannot  afford  the  time  most  standard  methods 
require  because  they  rely  primarily  on  the  analyst  for  the  modeling  and,  as  a  result,  require  the 
analyst  to  become  an  expert  in  very  complex  areas.  The  analyst  in  this  example  acted  as  a  model 
refiner  because  there  was  no  time  to  understand  adequately  the  application  area.  The  alternative 
would  have  been  to  require  everyone  in  the  company  to  become  an  analyst.  Scientists  and  medical 
technicians,  along  with  many  others,  resist  learning  a  complex  analysis  method  especially  when 
they  are  under  pressure.  This  is  not  surprising  since  they  are  highly  trained  and  their  concerns 
were  in  areas  other  than  systems  analysis.  While  evolving  the  system  model,  strict  adherence  to  a 
modeling  notation  impeded  communication.  Most  of  the  stakeholders  naturally  were  able  to  draw 
a  visual  representation  for  a  system,  and  flexibility  was  a  necessity,  since  the  stakeholders  were 
actively  doing  the  modeling.  Of  course,  it  may  be  possible  over  time  for  all  the  stakeholders  in  a 
single  company  to  adopt,  without  lengthy  training,  a  single  rich  notation.  In  fact,  during  this  case 
study,  some  of  the  people  did  use  the  notation  presented  to  them  by  the  analyst. 

Many  existing  modeling  techniques  do  not  take  into  account  the  people  issues  involved  in  de¬ 
veloping  complex  products.  Working  with  the  caliber  of  people  that  existed  in  this  project  was 
extremely  tricky.  They  were  considered  experts,  but  had  diverse  experiences,  with  opinions  that 
were  quite  entrenched  and  had  to  be  convinced  when  alternate  views  were  presented.  They  were  of¬ 
ten  impatient  with  the  engineers,  wanting  them  to  “just  go  away  and  build  the  machine”.  Bridging 
the  gap  in  this  situation  required  the  analyst  to  be  a  neutral  party  and  to  work  hard  to  adequately 
represent  the  concerns  of  all  the  stakeholders.  People  began  to  circumvent  the  requirements  process 
when  they  did  not  feel  adequately  involved  and  when  it  appeared  to  be  taking  too  long.  Equal 
opportunity  for  contribution  to  a  system  model  was  necessary.  Lengthy  face-to-face  communication 
with  very  diverse  people  was  not  an  efficient  use  of  time.  Many  times  during  face-to-face  meetings 
the  more  technical  people  of  the  group  dominated  the  discussion.  This  lead  to  divergent  conversa¬ 
tions  with  a  result  that  most  of  the  people  were  left  frustrated.  Having  a  system  model  in  which 
all  of  the  stakeholders  were  invested  anchored  the  communication,  and  meetings  were  held  only  as 
necessary  between  subsets  of  stakeholders. 

3  The  Facilitator  Method 

The  neutral  model  described  in  the  previous  section  is  called  an  Integrated  System  Model  (ISM) 
in  this  method.  The  analyst  role  in  the  example  is  termed  a  facilitator.  A  skilled  facilitator  is  able 
to  rapidly  iterate  to  an  ISM  that  is  useful  for  determining  requirements  by  using  the  prototypes  that 
exist  in  the  company,  the  market,  and  the  knowledge  of  the  experienced  stakeholders.  There  are  two 
parts  or  perspectives  to  the  ISM,  a  graphical  system  model  perspective  and  an  annotated  project- 
related  commitment  perspective.  Unlike  the  method  used  by  Leite  and  Freeman,  where  perspectives 
were  taken  in  parallel  to  formulate  each  viewpoint  and  then  combined  with  other  viewpoints,  the 
graphical  perspective  is  taken  then  combined  with  graphical  perspectives  held  by  other  stakeholders 
(Figure  4).  After  agreement  on  the  graphical  perspective  has  been  achieved,  the  second  perspective, 
the  commitment  perspective,  is  solicited  and  acts  to  validate  the  first  perspective.  By  resolving  the 
perspectives  in  series,  the  facilitator  method  capitalizes  on  the  strength  of  what  has  already  been 
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Figure  4:  Process  Diagram  for  Facilitator  Method. 

agreed  to  by  the  stakeholders. 

The  facilitator  begins  the  process  by  soliciting  a  block  diagram  of  the  system  from  each  of  the 
stakeholders.  This  block  diagram  does  not  have  to  use  any  specific  notation.  The  block  diagram 
is  based  on  whatever  preliminary  marketing  information  or  statement  of  need  that  is  available. 
Some  of  the  stakeholders  may  require  assistance  in  developing  this  first-cut  diagram,  but  even  if 
assistance  is  rendered,  it  is  important  that  the  block  diagram  is  owned  by  the  stakeholder.  Equal 
opportunity  for  unbiased  input  is  critical  at  this  stage.  Complete  system  requirements  from  each 
stakeholder  are  not  the  concern  so  much  as  representing  all  the  elements  that  are  important  to  the 
particular  stakeholder. 

The  individual  viewpoints  on  the  system  are  then  merged  by  the  facilitator.  The  technique  used 
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in  the  example  project  was  that  of  grouping  and  leveling  based  on  structured  analysis  methods.  In 
particular,  the  facilitator  first  examines  the  various  viewpoints,  looking  for  patterns.  This  involves 
trying  to  find  the  largest  scope  that  defines  what  is  being  called  “the  system”  by  defining  the 
boundary  between  what  is  inside  the  system  and  what  is  outside  the  system.  The  facilitator  then 
forms  logical  groups  of  functions  into  components  and  subsystems,  usually  based  on  communication. 

The  outcome  of  merging  should  be  the  graphical  portion  of  an  ISM.  The  ISM  does  not  have  to 
be  in  any  specific  graphical  notation,  but  a  notation  should  be  used  that  is  adequate  to  describe 
the  entire  system  and  that  can  be  understood  by  all  the  stakeholders.  Using  a  notation  that  is 
too  full  of  dichotomies  and  vocabulary  can  impede  communication  among  the  stakeholders  at  this 
level.  For  example,  in  the  case  study,  many  of  the  specialized  notation  for  the  structured  analysis 
real-time  extensions  confused  the  stakeholders  and  had  to  be  compromised. 

The  ISM  is  then  given  back  to  the  stakeholders  for  iterative  refinement  and  discussion.  At  this 
point  many  issues  will  arise  and  a  sort  of  synergy  of  thought  will  occur.  What  one  stakeholder 
has  included  will  spark  another  stakeholder,  and  the  diagram  will  undergo  tremendous  amounts 
of  change.  The  key  is  that  the  communication  is  all  anchored  to  the  ISM.  Issues  are  resolved 
in  a  series  of  face-to-face  meetings  that  include  subsets  of  the  stakeholders  with  or  without  the 
facilitator.  Once  the  issues  are  resolved  to  the  satisfaction  of  the  parties  involved,  a  modified  ISM 
is  given  to  the  facilitator.  In  the  project  described,  about  three  weeks  were  required  for  the  building 
of  the  original  graphical  ISM  and  two  weeks  for  feedback  to  be  returned  to  the  facilitator.  This 
time  was  reduced  as  the  process  was  used  more.  It  is  then  the  responsibility  of  the  facilitator  to 
turn  the  next  version  of  the  ISM  around  to  the  stakeholders  quickly.  The  iteration  continues  until 
the  ISM  more  or  less  stabilizes.  This  happened  within  about  four  to  six  iterations  in  the  case  study. 

The  facilitator  then  asks  for  specific  information  on  each  component  of  the  ISM  again  from  each 
stakeholder.  Since  this  information  is  more  specific,  each  stakeholder  will  not  be  able  to  supply  all 
of  it.  The  information  is  text  and  includes  specific  attributes  of  each  component,  resources  that 
will  be  required  to  design,  test  and  produce  each  component,  and  time  required  for  each  phase  of 
development.  Again,  the  reliance  here  is  on  past  projects  and  systems  that  have  been  developed 
and  on  the  experience  that  the  stakeholders  possess.  Estimation  techniques  and  consulting  with 
the  group  that  the  stakeholder  represents  may  be  required  to  get  the  detail  necessary.  The  reason 
to  ask  for  this  project-related  information  at  this  early  stage  is  to  make  explicit  all  assumptions  and 
areas  that  are  not  yet  well  defined  or  understood.  People  pay  close  attention  when  commitments 
need  to  be  made.  This  is  a  so-called  “truth-generating  mechanism”  [1],  When  the  data  from  the 
stakeholders  are  taken  in  aggregate,  they  reveal  what  is  not  known  about  the  system,  areas  of 
discrepancy,  and  risk  areas.  The  facilitator  takes  the  information  and  forms  as  complete  a  picture 
as  possible  from  the  data  given.  If  huge  discrepancies  occur — e.g.,  someone  says  it  will  take  two 
weeks  to  test  and  another  says  it  will  take  six  months — it  may  be  necessary  for  the  facilitator  to 
meet  with  a  subset  of  the  stakeholders.  Again,  the  merged  data  are  presented  to  all  the  stakeholders 
and  the  communication  sparks  fly.  This  communication  is  based  on  something  concrete  and  specific 
that  will  anchor  the  face-to-face  meetings  that  take  place.  The  graphical  ISM  is  subject  to  change 
at  this  point  as  more  things  become  apparent  to  the  group  of  stakeholders.  In  this  way,  the  second 
perspective  validates  the  graphical  model  that  was  achieved  previously.  The  feedback  in  the  form 
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of  a  modified  graphical  ISM  and  edited  annotation  information  is  given  to  the  facilitator  for  the 
next  iteration. 

A  complete  picture  of  the  annotated  information  may  not  be  possible  without  further  leveling 
of  the  ISM.  The  facilitator  uses  all  the  information  given  so  far  and  creates  a  first  cut  of  the  next 
level  of  the  ISM.  At  this  point,  stakeholders  may  change  for  each  specific  component  that  is  leveled. 
This  supports  the  first-level  phenomena  experienced  by  many  people  who  have  been  involved  in 
using  methods  like  structured  analysis.  This  phenomenon  happens  when  any  one  group  of  people 
will  only  go  down  a  couple  of  levels  until  the  level  that  they  are  concerned  with  is  resolved.  For 
example,  the  user  interaction  portion  of  a  system,  once  taken  down  a  level,  may  require  someone 
more  experienced  in  user  interfaces  and  may  not  require  the  radio  frequency  (RF)  engineer  to  be 
involved.  These  decisions  can  be  made  and  the  process  can  continue  with  new  sets  of  stakeholders 
for  the  various  components  in  the  system.  The  priority  in  this  process  is  to  get  a  completed  ISM 
at  the  highest  level.  Components  that  are  well  defined  and  do  not  have  holes  can  be  put  aside 
or  further  development  can  continue  concurrently  at  a  lower  priority.  Once  the  graphical  model 
and  the  annotated  information  are  complete  at  the  highest  level,  concurrent  engineering  efforts  can 
begin  in  earnest.  However,  the  use  of  a  facilitator  may  continue  until  the  stakeholders  are  more 
homogeneous  and  less  technically  diverse. 

The  outcome  of  this  process  is  a  multi-level  ISM  with  the  necessary  project  information  achieved 
rapidly  by  collaboration  and  consensus.  The  dependency  is  on  the  stakeholders  and  not  the  analyst. 
A  more  comprehensive  set  of  requirements  can  be  developed  quicker  by  using  the  people  and  their 
combined  experience  in  a  synergistic  fashion.  The  critical  information  that  is  provided  assists 
marketing  and  management  to  determine  the  feasibility  of  the  product  being  developed.  Trade-offs 
can  be  made  and  priorities  can  be  established  in  light  of  this  marketing  information.  Risk  areas 
can  be  defined  and  mitigated.  Engineering  and  production  efforts  can  be  based  on  these  decisions, 
and  a  viable  product  is  more  likely. 

3.1  The  Facilitator’s  Role 

The  term  facilitator  may  be  ambiguous.  It  was  chosen  instead  of  “neutral-intervenor” ,  “me¬ 
diator”,  or  “arbitrator”  because  of  its  ambiguity.  The  role  requires  definition,  but  there  was  no 
convenient  term  to  use  for  the  role  defined  in  this  process.  The  primary  role  of  the  facilitator  is  to 
build  the  ISM  based  on  information  given  by  the  stakeholders.  The  definition  given  by  Hall  for  the 
various  third  party  roles  is  that 

“A  facilitator  helps  with  the  logistics  in  the  proceedings  of  meetings.  A  mediator  guides 
or  helps  people  come  to  a  voluntary  agreement.  An  arbitrator  tries  to  understand  the 
issues  on  all  sides  and  then  imposes  an  agreement,  as  a  judge.”  [1] 

The  facilitator  in  this  process  does  a  little  of  each  of  these.  However,  their  primary  role  is  providing 
the  ISM.  The  ISM  should  embody  the  proceedings  of  meetings  held  by  the  stakeholders.  One  of  the 
logistics  that  the  facilitator  handles  is  managing  the  iteration  loops.  The  facilitator  in  this  process 
should  be  well  trained  in  system  design. 
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The  fact  that  there  are  diverse  stakeholders  and  many  issues  that  need  to  be  resolved  rapidly 
makes  developing  requirements  and  high-level  design  definition  an  “integrative  bargaining  prob¬ 
lem”  [f].  The  facilitator  reduces  this  “integrative  bargaining  problem”  to  a  “distributive  bargaining 
problem”  [f]  at  which  point  the  facilitator  is  no  longer  necessary.  It  may  take  multiple  facilitators 
to  achieve  this,  because  as  the  abstraction  levels  become  more  specific,  facilitators  with  different 
specialties  may  be  necessary.  To  accomplish  this  reduction,  the  facilitator  sets  up  a  dynamic  mech¬ 
anism  to  resolve  potentially  conflicting  views  of  the  system  or  subsystem.  These  conflicting  views 
are  a  rich  source  of  information.  This  dynamic  mechanism  starts  with  a  sort  of  bidding  about 
what  the  system  looks  like.  These  multiple  views  are  transformed  into  a  neutral  model.  Yet,  each 
stakeholder’s  concerns  are  not  overridden  or  forgotten  in  the  process  of  face-to-face  meetings. 

It  is  necessary  that  the  facilitator  be  independent  from  any  of  the  stakeholder  organizations. 
One  common  error  that  is  made  is  that  this  role  is  in  essence  filled  by  the  project  manager  who 
belongs  to  one  of  the  engineering  organizations.  The  requirements  document  that  results  is  very 
biased  toward  the  engineering  stakeholders  with  the  marketing,  users,  and  customers  left  figuring 
out  what  it  means  in  the  terms  they  care  about.  The  production  and  quality  staff  are  left  subservient 
to  whatever  the  engineers  devise.  In  the  case  study,  the  facilitator  was  made  a  neutral  party.  This 
was  very  helpful,  since  there  were  many  times  when  she  had  to  suggest  a  solution  that  was  not  in 
keeping  with  the  biases  of  the  engineering  managers. 

The  marketing  focus  is  a  grounding  in  the  reality  that  the  product  that  is  being  produced  has 
to  sell.  The  goal  is  to  negotiate  what  is  physically  possible  and  what  is  marketably  possible.  There 
may  not  be  a  margin  of  overlap,  but  it  is  up  to  the  facilitator  working  with  the  stakeholders  to 
quickly  figure  out  whether  or  not  there  is.  Figure  5  shows  that  if  there  is  an  overlap,  it  is  not 
static.  Therefore,  market  feasibility  for  any  one  product  defined  by  a  set  of  requirements  is  not 
static.  The  sense  of  urgency  in  achieving  requirements  definition  quickly  is  one  of  the  elements  that 
is  missing  in  many  requirements  elicitation  methods.  The  window  of  opportunity  for  any  potential 
product  shrinks  as  time  passes  and  risks  increase.  If  there  is  an  overlap,  then  a  solution  that  comes 
with  an  acceptable  risk  must  be  developed  as  quickly  as  possible.  The  facilitator  process  makes 
risk  areas  apparent  because  it  shows  discrepancies  in  how  stakeholders  view  the  system.  It  is  up  to 
the  facilitator  to  flag  the  risk  areas  and  pursue  them  with  the  appropriate  management  and  staff. 
Depending  on  the  situation  and  the  company,  this  may  be  done  by  assigning  a  team  to  mitigate  a 
specific  risk  area  or  re-negotiating  requirements  with  marketing,  whatever  is  necessary  to  get  the 
job  done. 

4  Conclusions  and  Future  Work 

The  facilitator  method  outlined  in  this  paper  is  a  practical,  systematic  approach  of  using  ex¬ 
perienced  stakeholders  to  achieve  requirements  definition  rapidly.  It  is  based  primarily  on  the 
experience  presented  in  Section  2.  The  need  for  speed  in  defining  requirements  for  a  product  is 
paramount  given  most  marketing  environments.  The  use  of  a  facilitator,  rather  than  a  formal 
analyst,  speeds  up  the  process  of  developing  a  system  model  that  can  be  used  for  requirements 
specification.  This  can  be  achieved  with  some,  but  effectively  little,  impact  on  completeness,  using 
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Figure  5:  Non-static  Market  Feasibility  for  Any  Single  Product  Defined 
by  Requirements. 


viewpoint  resolution  [2]  as  modified  for  this  method.  The  use  of  a  commitment  perspective  helps 
validate  the  graphical  model  perspective  of  the  ISM  and  it  provides  the  measure  by  which  a  project 
should  be  evaluated.  This  method  can  be  scaled  to  small  projects  but  is  most  effective  for  large, 
complex  projects  such  as  the  case  study  described  in  this  paper. 

This  method  needs  to  be  tested  on  controlled  projects  to  determine  how  much  training  a  fa¬ 
cilitator  would  require  in  addition  to  a  standard  systems  engineering  background.  The  interaction 
and  potential  problems  that  can  occur  with  an  ineffective  facilitator  needs  to  be  investigated  fur¬ 
ther.  The  facilitator  could  potentially  become  a  bottleneck,  but  no  more  so  than  a  project  leader, 
a  product  manager,  or  someone  in  a  similar  systems  role.  Controlled  studies  would  be  useful  in 
determining  wliat  impediments  a  facilitator  would  have  to  overcome  to  be  effective.  In  the  case 
study,  it  was  determined  that  ownership  of  the  ISM  by  all  of  the  stakeholders  is  critical.  The 
facilitator  is  key  in  fostering  this  ownership.  Specific  ways  a  facilitator  can  cultivate  this  ownership 
is  an  area  that  would  require  controlled  studies. 

The  type  of  graphical  notation  used  primarily  at  the  highest  levels  of  abstraction  needs  further 
investigation.  A  notation  that  is  natural  for  people  from  diverse  disciplines  would  be  most  useful. 
Block  diagrams  of  different  flavors  seemed  to  be  a  common  method  of  communicating  by  most  of  the 
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stakeholders  in  the  case  study.  The  marketing  staff  drew  block  diagrams  as  did  the  scientists  and 
production  people.  Some  questions  still  remain:  how  much  information  is  communicated  in  common 
block  diagrams  and  how  rich  does  a  notation  have  to  be  to  achieve  the  level  of  understanding 
required  for  the  facilitator  method  to  be  effective?  Another  aspect  of  the  graphical  notation  is  the 
use  of  specialized  tools.  The  goal  would  be  for  the  stakeholders  to  use  whatever  graphical  editor  is 
most  convenient  for  them  to  use.  Given  the  diversity  of  the  stakeholders  for  a  large  project,  a  tool 
that  is  too  restrictive  can  cause  a  stakeholder  to  be  less  effective.  The  cost  of  investing  in  a  tool, 
especially  in  terms  of  time,  should  not  be  an  obstacle  to  using  the  facilitator  method. 

The  specific  information  that  needs  to  be  annotated  in  the  commitment  perspective  is  another 
area  that  needs  further  investigation.  This  information  could  potentially  vary  from  company  to 
company  and  between  abstraction  levels  for  a  single  project.  This  information  should  allow  the 
determination  of  product  feasibility — i.e. ,  is  there  an  overlap  between  what  the  market  requires 
and  what  the  developers  can  realistically  produce?  The  annotated  information  must  flag  risk  areas 
and  provide  a  means  to  validate  the  graphical  model  perspective  of  the  ISM. 
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